1. Field of the Invention
The present invention relates generally to object-oriented programs, and more specifically to detecting memory leaks in an executing object-oriented program.
2. Description of the Related Art
Most of the programming languages/run time systems support dynamic memory allocation and reclamation. In object-oriented languages, memory can be reserved and released on a per-object basis, e.g., through object allocation and reclamation. In some languages, for example, C++, freeing memory occupied by an object is done explicitly, by calling a special system function. In other object-oriented languages, e.g., Java, that support so-called automatic memory management, memory occupied by objects that are not in use anymore is reclaimed automatically by a run time subsystem called a garbage collector. In Java, an object is considered unused and available for reclamation if it is not reachable directly or transitively from any object graph root. These roots (omitting some second order implementation specific details) are stack frames, i.e., object type local variables of currently executing methods, and object type static variables of currently loaded classes.
A memory leak in a program written in a language such as C++, with manual memory management, is a well-known problem that happens when a program does not explicitly free some objects or memory area that is previously reserved. If in the course of program execution, allocations without reclamation repeat over and over again, these allocations may ultimately exhaust all the available memory, causing the program to crash.
It should be appreciated that even in a language such as Java, that features automatic memory management, it is still possible to have memory leaks. Such leaks happen when some object remains reachable, but is not used anymore. That is, the program does not read or write its data fields. For example, a program may allocate a temporary object, attach it to some permanent automatically growable data structure, such as an instance of java.util.Vector. This temporary object is used for some period of time and then (logically) discarded. However, the object remains attached to the permanent data structure and cannot be reclaimed by the garbage collector. Over time, a large number of such unused objects can exhaust the memory available to the program, making the latter stop.
Another type of memory leak occurs when a data structure is designed poorly and keeps growing in an unlimited manner. A classical example is a persistent object cache that is not flushed properly. Strictly speaking, objects in such a cache are not unused, i.e., the program can request any of them at any moment. However, if the cache does not take care of evicting some objects periodically, it may ultimately grow too large, thereby exhausting the memory available for the program.
In light of the foregoing, it is desirable to implement a scheme for a method to identify memory leaks occurring in an object-oriented program in a manner that does not impose noticeable runtime overhead.